Electronic commerce (“E-Commerce”) is a distributed computing environment with dynamic relationships among a large number of autonomous service requesters, brokers and providers. One goal is to automate e-commerce applications by using software agents that cooperate to perform business transactions. Unfortunately, multi-agent cooperative transactions have requirements that are different from conventional transactions. Consequently, the prior art mechanism to handle transactions are not adequate to address the needs of multi-agent cooperative transactions.
An E-Commerce scenario typically involves well-known business activities and transactions. Example of these activities and transactions include 1) identifying requirements, 2) brokering products, 3) brokering vendors, 4) negotiating deals, 5) making purchase, and 6) making payment transactions. Today, these activities are initiated and executed primarily by humans. For example, an individual in a first company (e.g., company A) that is in need for a good or service contacts another company (e.g., company B) that may offer a desired good or service. A person in company B in turn answers questions about the suitability, availability and price of the requested good or service. In a larger company, different departments within the company can be delegated the tasks of determining product or service requirements, determining suitable vendors, negotiating a purchase, payment, etc. The growth of the Internet has simplified business transactions by allowing a vendor to offer information about its goods or services on its web site. In addition, limited on-line ordering and payment for goods and services may be provided at a web site.
Instead of having to speak with a person at company to determine the specifications and price of goods or services, one can simply access a relevant web page at the web site of the company being investigated. However, it is noted that human intervention is required at many steps in a typical business transaction. For example, even when the information is available on the Web, a person still needs to go to the specific web page, browse different pages to find the appropriate good and service, etc. Even if the order is placed on-line, a person must provide the payment information, ship-to information, etc. On the other end, a person or department is needed to manually process each order or request.
In the future, with the increasing automation of e-commerce, we see them being conducted by software agents. Software agents are personalized, continuously running and semi-autonomous computational entities that are driven by a set of beliefs, desires and intentions (BDI). They can be used to mediate between users (clients) and servers (service providers) to automate a number of the most time-consuming tasks in E-Commerce [3,16,18,19,20,22]. Moreover, agents can selectively preserve data and themselves become dynamic information sources, or data containers. E-Commerce automation can thus be accomplished through multi-agent cooperation, where agents perform various market activities and cooperate by exchanging data as well as programs.
One feature that distinguishes Internet-based e-commerce from traditional “brick and mortar” commerce is that agents can form dynamic partnerships that exist for only as long as they are needed. For example, agents that re-sell products, agents that supply products, and agents that provide brokering services may form a dynamic partnership for the duration of a specific business transaction. Also, agents may switch roles; for example, an agent may be a buyer in one transaction, a broker in another, and seller in a third. With the growth of the Internet and the information superhighway, the growth of electronic commerce (i.e., an increase in the number of electronic storefronts that offer products and services across the web) has also exploded. Dynamic agents and an electronic commerce infrastructure in which the dynamic agents can be deployed are described in greater detail in a publication entitled, “Dynamic Agents”, by Q. Chen, P. Chundi, Umesh Dayal, M. Hsu, International Journal on Cooperative Information Systems, 1999, which is hereby incorporated by reference in its entirety.
An exemplary buy-sell transaction or process is described herein below. A typical purchase process can include the following individual transactions: 1) an order transaction (Torder), 2) a processing transaction (Tproc), 3) a payment transaction (Tpayment), and 4) a shipping transaction (Tship). Each of these transactions can be carried out by software programs (referred to herein as agents) that belong to the parties of the transactions. For example, the parties to the transaction include a buyer, a seller, and a bank that issued a credit card to the buyer, respectively.
There are generally three prior art approaches that can be used to model such a purchase transaction. These approaches include 1) distributed transactions, 2) nested transactions, and 3) transactional work-flows. As described herein below, theses prior art approaches to model a purchase transaction are inept to accurately describe a transaction across enterprises, and as such are limited to transactions occurring within an enterprise (i.e., intra-enterprise transactions).
Purchase Process Modeled as a Distributed Transaction
In the typical approach to implementing a distributed transaction, a transaction processing (TP) monitor is employed for providing centralized control. The sub-transactions (e.g., Torder, Tproc, Tpayment, and Tship) participate in a two-phase commit protocol that is coordinated by the TP-monitor. Unfortunately, in a real purchase process the buyer, seller, and bank agents belong to different enterprises. Consequently, the use of a single TP-monitor is unrealistic for this situation.
Purchase Process Modeled as a Nested Transaction
A second prior art approach is to model the purchase process as a nested transaction. In this approach, a top-level transaction (Ttop) is needed and must be introduced. In this regard, the transactions, Torder, Tproc, Tpayment, and Tship have to commit to Ttop, (i.e., the effects of the transactions are made persistent through the top level transactions (Ttop)). Unfortunately, as noted previously, the buyer, the seller and the bank are independent enterprises. Consequently, the transactions Torder, Tproc, Tpayment, and Tship commit to their own databases. It is difficult, if not impossible, for a buyer to make the seller commit to the buyer's database since the transactions are distributed across enterprises. Therefore, implementing the conceptual transaction Ttop is not a trivial task and unrealistic for this situation.
Purchase Process Modeled as a Transactional Workflow
A third prior art approach models the purchase process as a transactional workflow. A workflow system provides flow control for business process automation. A business process often involves multiple steps, such as Torder, Tproc, Tpayment, and Tship. Each step represents a logical piece of work that contributes to the process. A workflow process represents the integration and synchronization of multiple actions. Although these actions and the agents that execute the actions can be distributed, the actions and agents are scheduled and coordinated by a centralized workflow engine. However, as illustrated in this example, the purchase process typically involves tasks that are executed in different enterprises, which are not under the control of a single workflow engine.
Based on the foregoing, there remains a need for an apparatus and method for modeling cooperative transactions to automate electronic commerce through the use of dynamic agents.